Identity management in its widest sense means management of all the personal information about a person, including at least all the person's digital relations. Over the next decade, identity management systems in this wide sense are likely to evolve. Short-term, identity management is typically said for web single sign-on with the transfer of a small amount of data about a person.
Single sign-on enables a person or user to log in to different organizations or services, while remembering only one password, and thus authenticating only once, without allowing all the organizations to impersonate the person towards each other as simply as using the same password directly with all organizations would. Furthermore, single sign-on protocols allow client applications to identify themselves to other applications with whom they had not a priori exchanged any common data, such as keys. Usually, a user chooses the same username and password with all the organizations or services, which is problematic. Each service can impersonate the user towards the others. This may be acceptable for services of one enterprise, but even there one would prefer better modularization. And clearly it is not acceptable for a user's overall web experience. Services that need initial identification of the user, with respect to a preexisting identity, would still all need to perform this identification. An object of a real single sign-on protocols is therefore to solve these problems.
Single sign-on is widely seen as a necessary infrastructure to make electronic business on the Internet easier and to allow widespread use of the emerging Web Services. It may also evolve into more general identity management, e.g., for exchanging additional information about a person once the identity has been established.
Known single sign-on solutions include, for example,
Microsoft Corporation's Passport system (URL: http://www.passport.com),
the OASIS (Organization for the Advancement of Structured Information Standards) standardization of the Security Assertion Markup Language (SAML) (URL: http://www.oasis-open.org/committees/security/docs), and
the Liberty Alliance Project's recent specification (URL: http://www.projectliberty.org). An aspect in the Liberty specifications is that detailed protocols are provided not only for browsers as client applications, but also more efficient protocols for other, more powerful client applications. Older related schemes in this setting are classical three-party authentication protocols.
None of the known products and proposals fulfills all the following requirements, which seem to be relevant for non-browser client applications in an Internet-based scenario:                Req 1: Security against a man-in-the-middle attack, i.e., not even a rogue service provider should be able to impersonate a correct client application to another service provider.        Req. 2: No need for cryptography in the client application beyond secure channels, such as Secure Socket Layer (SSL) or its successor Transport Layer Security (TLS), used through their normal interfaces.        Req. 3: Better efficiency than by implementing a protocol that was designed for a browser client.        
Classical three-party authentication protocols like Kerberos, Needham-Schroeder all start with a key-exchange or key-confirmation protocol and then require the client application to use this key for encryption and authentication. In other words, a third party that can identify the client application by some a-priori exchanged information, such as a password, secret key, or confirmed public key, typically generates a new secret key for communication between the client application and its partner entity, which herein is called “requesting entity”, and transfers this secret key securely to both these entities. There is a great variety of protocols for carrying out this secure transfer of the secret key. Another variant is that the third party only gives an online confirmation (certificate) of a public key of the client application. However, after each of these protocols, the client application has to use the new or confirmed key in the communication. This conflicts with the second requirement (Req. 2), which says that the client application need only use a secure-channel protocol through its normal interface, without any cryptography of its own.
One could also, in contrast to the third requirement (Req. 3), implement any protocol intended for browser clients on non-browser clients. However, this is unnatural and inefficient for other client applications such as Web Services: On the one hand, they would need detailed functionality of browsers only for this purpose, e.g., redirection and understanding cache control. On the other hand, browser protocols have certain limitations which are no longer necessary with a normal client application. For instance, a redirect can only be made to an a-priori known party. Hence, if the requesting entity initially does not know which third party holds information about a certain browser user, it first needs steps to find that out, and then the redirect can start. In contrast, a normal client application can be programmed to understand a request of the form “please forward this question to the third party holding your identity-related information”. This saves two steps and thus an Internet round-trip. Furthermore, a browser can at most carry information, such as a request for identity-related information or the returned identity-related information, unchanged from one party to the other (using a redirect), but not make any verifications on this information itself.
The combination of the second and third requirements (Req. 2 and 3) was so far only addressed by the Liberty Alliance Project (URL: http://www.projectliberty.org), more precisely in its “Liberty Bindings and Profiles Specification”, Version 1.0, 11, Jul. 2002, Section 3.2.5, “Liberty-Enabled Client and Proxy Profile”. However, this protocol does not fulfill the first requirement (Req. 1), security against man-in-the-middle attack: A rogue service provider (e.g., the owner of a web shop) to whom the client application is currently identifying can impersonate this client application to another service provider (e.g., the client's bank, or a company that has a supply-chain relation with the client's employer) and thus harm the user, or harm the other service provider by doing mischief with the user's privileges. The problem is that the rogue service provider can, in its request for identity information, combine the name of the other service provider with its own (the rogue service provider's) address. Then it gets a “ticket” suitable for identifying to the other service provider sent to its own address, and can subsequently use it. From the above it follows that there is still a need in the art for an improved single sign-on or authentication system for arbitrary client applications using existing secure channels and preventing man-in-the-middle attacks.